Hello,
This has actually been fixed last friday with 9e0517a (see #5249, #5293)

This has actually been fixed last friday with 9e0517a (see #5249, #5293)

Actually not exactly. We fixed something very close to that, and I would say it is extremely likely that your case would be fixed by our change, but I'm not 100% sure since they are done at different level of code.
I cannot merge an extra random bound check without an understanding of what would repro it.

Sorry, I do not recall the exact scenario it happened with. Somehow it got called with a negative value. It would be good for this to be fixed regardless, as it did happen in normal usage. The end users were calling an abstraction via Lua bind.

I noticed some of those bounds checks up the call stack and I'm unaware if those had existed back a few months ago. It could've fixed the issue but I am now unable to reproduce it.

If you really think the bounds check on this function is unnecessary, then sure... but make it more verbose that this never receives a negative value.

In the current code it would make a difference if private/internal _CalcCircleAutoSegmentCount() function is called with a negative radius. Looking at the 3 call sites I don't see how that's possible so IHMO there's no bug right now (unless _CalcCircleAutoSegmentCount() is called directly, which is technically illegal as it is a private API).

What puzzle me is how precisely the PR you are suggesting would fix anything even in the old version. Your fix protects against NEGATIVE radiuses but all calls to _CalcCircleAutoSegmentCount() already had a radius <= 0 check for that. My guess is that the crash you had was not an OOB but the divide-by-zero when pulling from CircleSegmentCounts[0], bug outlined and fixed in #5249. Your fix didn't actually fix that, maybe but it's just that you experienced the crash rarely enough you thought it was fixed. If you trace the code prior to your patch the call sites make it pretty obvious. If your fix used radius_idx > 0 I understand how it would make a difference, but I can't see a difference being made with radius_idx >= 0.

Turns out this could repro which an excessively large floating point value (e.g FLT_MAX or even e.g. 100000000.0f) which would break during the downcast to int. See #6657. Merged same fix.